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Abstract 

Cognitive Agent Architecture (Cougaar) is a Java-based 
architecture for large-scale distributed agent-based appli- 
cations. A Cougaar agent is an autonomous software en- 
tity with behaviors that represent a real-world entity (e.g., 
a business process). A Cougaar- based Model Driven Archi- 
tecture approach, currently under development, uses a de- 
scription of system's functionality (requirements) to auto- 
matically implement the system in Cougaar. The Commu- 
nicating Sequential Processes (CSP) formalism is used for 
the formal validation of the generated system. Two main 
agent components ; a blackboard and a plugin, are modeled 
as CSP processes. A set of channels represents communi- 
cations between the blackboard and individual plugins . The 
blackboard is represented as a CSP process that commu- 
nicates with every agent in the collection. The developed 
CSP-based Cougaar modeling framework provides a start- 
ing point for a more complete formal verification of the au- 
tomatically generated Cougaar code . Currently it is used to 
verify the behavior of an individual agent in terms of CSP 
properties and to analyze the corresponding Cougaar soci- 
ety. 


1. Introduction 

Agent-based systems provide a foundation for the devel- 
opment of large-scale applications such as logistics man- 
agement, battlefield management, supply-chain manage- 
ment, to mention just a few. An example of agent-based 
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systems is Cognitive Agent Architecture (Cougaar) [1, 2]. 
Cougaar provides a software architecture for distributed 
agent-based applications in domains characterized by hier- 
archical decomposition, tracking of complex tasks, genera- 
tion and maintenance of dynamic plans. 

The ability to develop very complex applications comes 
at a price. It takes a lot of effort and learning in order to have 
complete understanding and the ability to effectively use 
such agent-based systems. Cougaar’s capabilities and the 
complexity of the systems implemented in Cougaar bring 
additional demands for analysis, testing, and verification. 
Existing techniques can be adapted to deal with these de- 
mands. 

The Model Driven Architecture (MDA) approach [15] 
can be used for developing applications using 'the Cougaar 
agent-based architecture. The Cougaar MDA (CMDA) pro- 
vides automated software-artifact generation and simpli- 
fies Cougaar-based application development by providing 
two abstraction layers. Requirements are translated into the 
General Domain Application Model (GDAM) components. 
Die GDAM components are then translated into the General 
Cougaar Application Model (GCAM) components which 
are used to automatically generate the Cougaar code (soft- 
ware applications) [8J. 

As a first step for the formal verification of the gener- 
ated Cougaar-based system, a formal model is used to ver- 
ify the behavior of a Cougaar agent. Single-agent and multi- 
agent communications models provide a framework for the 
formal verification of requirements specifying a Cougaar- 
based application and its properties. Hoare’s Communicat- 
ing Sequential Processes (CSP) formalism [5, 12, 18] is 



used to develop a formal model of a Cougaar agent and a 
simple CSP model of a Cougaar-based system. 

The remainder of the paper is organized as follows. Sec- 
tion 2 briefly describes Cougaar and its capabilities. Sec- 
tion 3 describes approaches to the modeling of agent-based 
systems. Section 4 discusses the CSP-based Cougaar model. 
Section 5 provides an example, while Section 6 concludes 
the paper. 

2. Cougaar Agent-Based Architecture 

Cougaar is a large-scale workflow engine built on a 
component-based distributed agent architecture [1]. It is de- 
ployed as a society of agents, which communicate and work 
together to solve a problem. A Cougaar society is a set 
of agents running on one or more interconnected comput- 
ers, all working together to solve a common class of prob- 
lems. The problem may be partitioned into sub-problems, in 
which case the responsible subset of agents is called a com- 
munity. A society may have one or more communities. The 
relationship between societies, communities, and agents is 
not a strict one; a society may directly contain both agents 
and communities. While a society has a real-world repre- 
sentation, a set of computers running a Cougaar system, a 
community is only notational in nature. 

Some recent efforts in addressing Cougaar architectural 
characteristics include performance and survivability en- 
hancements. There are many different requirements on the 
metrics collection and communication channels [10]. Per- 
formance improvements and measurement require the use 
of multiple communication channels to improve overall per- 
formance with some data duplication overhead. A general 
approach for dynamically improving overall system surviv- 
ability for the large class of applications is described in [9]. 
Constraints include finite resources, multiple dimensions of 
success, and global optimization of the goal. 

2.1. Agent 

A Cougaar agent is a first-class member of a Cougaar So- 
ciety [1] and it contains a Blackboard and one or more Plu- 
gins. While the specific purpose of any agent is chosen by 
the system developer, the objective is for a single agent to 
represent a single organizational entity or part of that en- 
tity. 

At the most basic level, an agent consists of two parts: a 
Blackboard and a set of Plugins (Figure 1). The former is a 
container of objects, with a subscription-based change noti- 
fication mechanism; the latter is a set of responders to these 
notifications, with the ability to change the contents of the 
Blackboard. 

The Blackboard serves as the communications backbone 
connecting the Plugins together. More importantly, it serves 



Figure 1. Cougaar Agent Structure [1] 


as the entry point for any incoming messages to the agent as 
a whole, which are then picked up by the Plugins for han- 
dling. All instance-specific behavior of the agent is imple- 
mented within the Plugin. A Plugin listens to add , remove , 
and change events on the Blackboard. Evaluating the ob- 
jects involved in the event, die Plugin may respond by per- 
forming some computation changes to the Blackboard, or 
some external work. 

A Cougaar Node conceptually encapsulates a set of 
agents. Agents can collaborate with other agents in the 
same Node or with agents in other Nodes. However, it is 
not a direct collaboration. Instead, Cougaar Tasks are allo- 
cated to Cougaar Organizations, which are representations 
of agents in the local Blackboard. The subscription mecha- 
nism allows agents to use Tasks to exchange messages (ob- 
jects). The Cougaar communication infrastructure then en- 
sures that the Task is sent to the destination Organization’s 
(i.e. agent’s) Blackboard. 

2.2. Multi-Agent Communications 

Cougaar’s multi-agent communications system is quite 
sophisticated. There are several ways for agents to commu- 
nicate with each other. The methods are mostly based upon 
a Plugin, be it a specialized or a library component, observ- 
ing one agent’s Blackboard and propagating relevant data to 
another. 

2.3. Cougaar Model Driven Architecture 

The MDA approach advocates converting a Platform In- 
dependent Model (PEM) into a Platform Specific Model 
(PSM) through a series of transformations, where the PIM is 
iteratively made more platform-specific, ending in the PSM. 
The PIM is used to represent system’s functionality without 
including any technical aspects (Table 1). 


The encoding of requirements is done in stages using the 
“separation of concerns” principle. First, the workflow of 
the intended system needs to be drawn up. Then, the re- 
quired domain components are retrieved from the reposi- 
tory, the parameters for the components are provided and 
the components are linked to obtain the domain model of 
the system. The platform-independent model is represented 
in the General Domain Application Model (GDAM) layer, 
while the General Cougaar Application Model (GC AM) 
layer provides the platform-specific model. Once the do- 
main model is validated, the developers can check and en- 
sure that the GCAM components required to implement the 
domain model are present and linked properly. The linked 
GCAM components represent the application model of die 
intended system. Developers also ensure that the require- 
ments captured in the domain level have been transformed 
into application parameters properly. Once the domain and 
application models are properly built, the user can instruct 
the system to convert the models into required software arti- 
facts including Requirements, Design, Code and Test cases. 
The transformation of the models into software artifacts is 
handled by the compiler of the Cougaar Model Driven Ar- 
chitecture (CMDA) system. Once the compilation is com- 
plete, the user is informed of errors and warnings. Hence 
the CMDA system deals only with requirements collection 
from the user and allows asm to verify the requirements 
that have been properly transformed into application model 
parameters. 


Computationally Independent Model 

(input requirements) 

Platform IndependentModel 

(GDAM) 

Platform Specific Model 
(GCAM) 

Table 1. Basic CMDA Approach 


The following goals and priorities were formulated in or- 
der to develop a tool based cm the proposed approach [8]: 

• Fully automated software artifacts (requirements, de- 
sign document, code, and test cases) generation is a 
desirable goal. 

• The generated requirements are partial in nature. 

• The development of tools and implementation mech- 
anisms are of lower priority than formulating the 
“recipes” for transformations. 


3, Modeling Agent-Based Systems 

Large agent-based systems usually operate in a distrib- 
uted manner and depend on the underlying communication 
infrastructure designed for a specific system. Sound theo- 
retical concepts can provide solutions for distributed multi- 
agent systems that are superior to “usual” ad-hoc implemen- 
tations [3}. 

Suitability of agent modeling techniques to agent-based 
systems development is discussed in [20]. It provides direc- 
tions for research and development of agent-oriented mod- 
eling techniques. A set of criteria is proposed, based on the 
desired characteristics, for appropriate modeling techniques 
and approaches. 

The Specification Language for Agent-Based Systems 
(SLABS) [19] is based on a meta-model of multi-agent sys- 
tems. An agent-based system is modeled at two levels. The 
macro-level describes the relationships among agents. The 
micro-level describes the behaviors of individual agents. A 
diagrammatical notation includes collaboration, behavior, 
and scenario diagrams. 

Petri nets [7, 16] are used extensively in modeling, sim- 
ulation and analysis of distributed and multi-agent systems. 
Predicate/transition nets, a form of high-level Petri nets, can 
be used to construct a multi-agent model where transitions 
represent agent capabilities [24]. Analysis of Petri net prop- 
erties like reachability, liveness, etc., are used to verify that 
the multi-agent plans indeed achieve their goals. 

DESIRE is a framework for compositional systems (in- 
cluding multi-agent systems) [4], It uses hierarchical task 
decomposition and supports specification of agents that in- 
tegrates reasoning with interactions (communication, obser- 
vation and actions execution) and executive autonomy. The 
semantic approach based on temporal logic is outlined and 
applied for the case of compositional multi-agent systems. 

The TYPELAB system provides a reflective architecture 
for formalizing and reasoning about artifacts created dur- 
ing a software development process [17]. Object- and meta- 
level reasonings are combined using reflection principles to 
generate “standard” units. 

The CSP formalism uses a simple event-based descrip- 
tion and algebra for the description and analysis of systems 
[1 1, 12]. Originally designed for Transputers [23], it pro- 
vides a solid theoretical foundation for modeling software 
system behavior and formally proving properties. 

The core CSP components are processes and events. An 
event is an atomic, named entity. A process is a definition 
of allowable sequences of events. It is defined as a set of 
events with arrows (—►) between them. 

Processes may use recursion, conditionals, states, and 
references to other processes to define these sequences. A 
process’ state may be shown as a subscript. Processes may 
be composed together using the parallel operator ( ||), such 




that the actual event that occurs determines which of the 
processes executes. 

Processes communicate through fixed, named, unidirec- 
tional channels. Such channels have exactly one fixed in- 
put process, and exactly one fixed output process. The act 
of sending a message over the channel is actually an event 
with two different names in the two processes. An output 
event is shown as a channel name followed by an exclama- 
tion point, followed by the message being sent For exam- 
ple outfm sends die message m over the channel out. Input 
events use to similar notation, with a question mark replac- 
ing the exclamation point 

CSP can be extended, for example, to include priority 
specifications [6]. Appropriate algorithms can be developed 
to analyze properties of distributed systems that use a CSP- 
like communication infrastructure [13]. CSP models for a 
specific programming language implementations further in- 
crease modeling capabilities (e.g. for Java [22]). 

4. CSP Framework for Cougaar-based sys- 
tems 

The control architecture of to Cougaar distributed agent 
system [14] consists, at to node level, of the following 
components: 

• Operating mode: a data structure for control inputs. 

• Conditions: generalized sensor input information. 

• Plays: control laws (restrictions on operating modes 
and conditions). 

• Playbook: a list of plays tested in sequence for current 
conditions. 

• Playbook manager: a component maintaining and ma- 
nipulating a playbook. 

• TechSpecs: a high-level description of components be- 
havior. 

• Adaptivity engine: a controller for to agent and some 
other external components. 

• Operating mode policy: higher-level system policy. 

This control architecture can be easily adopted for vari- 
ous applications. Given the characteristics of an agent-based 
system, it is difficult to apply conventionally control theory 
methods directly [14]. Large-scale parallelization and seal- 
ability is achieved by using a multi-tier communication in- 
frastructure where each tier uses different communication 
techniques [21]. The CSP-based Cougaar modeling frame- 
work can provide a formal framework to analyze behavior 
of a single agent and its interactions with other agents. 


4.1. Single Agent 

There are two assumptions used in developing the CSP 
model of an agent: 

• The Plugins attached to a given agent are fixed. All 
Plugins are known at the start and the set cannot 
change over time. However, a Plugin may decide to 
start or stop participating with the agent it is connected 
to at any time. 

• A subscription mechanism is replaced by a broad- 
cast mechanism. Each Plugin is notified of every add, 
change , and remove occurring on its Blackboard. 

These assumptions may affect to accuracy and effi- 
ciency of the systems. The model accuracy can be preserved 
by introducing a Unary Predicate that filters Blackboard 
events. Upon reception of a Blackboard event, the Plugin 
can evaluate its Unary Predicate, and ignore the event if 
the predicate returns false. If the actual Plugin is only sub- 
scribed at certain times, we model its subscription state as 
a state variable s. Then, the UnaryPredicate can simply run 
with an additional requirement, that s = true. Reduced ef- 
ficiency, while important for deployment, is not relevant for 
modeling the system. 

An agent is defined as: 

A =< B 0 yP > 

where Bo is to Blackboard, O is the set of objects, P — 
{pi i P 2 , * • Pn } is the set of Plugins, and N is the number 
of plugins in P. 

4.2. Communication 

Before getting into the details of the agent’s components, 
it is necessary to describe the communications channels be- 
tween the Blackboard and the Plugins. The Blackboard de- 
fines N input channels (/? 1} . . . . #v). These channels accept 
input from the respective Plugins (pi, . . . , pw). The Black- 
board sends its notifications to the Plugins via the respec- 
tive channels (pi, . . . , pn)- 

43. Blackboard 

The Blackboard contains objects, which are modeled as 
an embedded pairs. 

object =< types , attributes > 
types = 

attributes = {< name i, valuei >, < name 2 , value 2 

The object represents any arbitrary object that can be 
put on the Blackboard. In the actual system, this is an in- 
stance of a Java class. The class is always a descendant of 



the Object class. The object is an ordered pair of types and 
a attributes. The types is the set of names, including the ob- 
ject’s real type, and the names of all supertypes. The types 
always contain the element Object due to Java’s inheritance 
model where the Object class is the root of the Java class hi- 
erarchy. The attributes is the set of object attributes repre- 
sented as < name , value > pairs. The set of all possible 
objects is defined as O. 

The Blackboard is modeled as the CSP Process Bo with 
the state O = {oi, 02 , * • «} representing the set of the cur- 
rent Blackboard objects. O is always a subset of O. The al- 
phabet of the Blackboard’s CSP process Bo includes sym- 
bols add, change , remove , and all the objects in O. 

'add, ' 

aB 0 = < change ' , 

remove , 

, oroeO , 

The subprocesses of the Blackboard, Add, Chg , Rem , 
and Notify are shown in Figure 2. Add, Chg , and Rem 
take in the object o from the same input channel, update 0 
as needed, and call Notify to notify the Plugins. Notify* s 
definition is simple, it sends the event e (be it add , change , 
or remove) and the object o to all the Plu gins via their in- 
put channels. 

4.4. Plugin 

A Plugin pi is a CSP process that: 

1. Belongs to an agent. 

2. Listens on an input channel p* for events. 

3. Decides if each event is relevant. 

4. If relevant, acts in response to it, possibly resulting in 
additional events on the Blackboard. 

The first and second steps have already been de- 
scribed. The third step is essentially a model of the Cougaar 
Unary Predicate. As shown in the Blackboard model, a 
CSP process can use conditional statements. An exam- 
ple of a simple unary predicate is shown in Figure 3. 
and the corresponding CSP model is shown in Fig- 
ure 4. 

The subprocess Pred(o) acts as a predicate, proceeding 
forward when the object matches, recursing back to pi when 
not. The other subprocess, Act(o) is the response action to 
a satisfied predicate. In this case it simply posts a String 
with value "PAID" to the Blackboard. 

4.5. Multiple Agents 

The support for multiple agents and their interactions is 
provided by the middleman that maintains channels with all 


process 

B 0 = 

let 

process 
Add(0,i) = 

if o O then O := 0 U { 0 } 
— * Notify(add , 0 ) 
else STOP 
Chg(i) = 

Pilo -* 

if 0 £ O then STOP 
else Notify {change, 0 ) 
Rem{0, z) = 

ft?* - 

if o 6 O then O O \ { 0 } 
— ► Notify {remove, o) 
else STOP 
Notify {e, o ) = 

V z € iV, {pi\c — * pt\o ) — > Bo 
\\^ =l Pilcmd 

if cmd = add then Add{0, z) 
if cmd ~ change then Chg{i) 
if cmd — remove then Rem{0, i) 
else STOP 


Figure 2. Blackboard 


the Plugins in the system, and relays messages to a new in- 
put channel for each Blackboard. Each Agent, Plugin, and 
Blackboard are uniquely named within the global scope. 
That is achieved by adding another subscript, a, to every 
identifier. This subscript identifies the Agent/Blackboard. 
The middleman's channels coming in from each plugin in 
the system would be p a . corresponding to the channel’s 
source, the Plugin p a ,i- The channels going out from the 
middleman to each Blackboard are named (3 a , o- 

5. Example 

The Dining Philosophers problem [16] is used as an ex- 
ample. In this problem, there is a circular table with D 
seats, D forks, and with a bowl of spaghetti in the mid- 
dle. At random intervals, any one of D philosophers sits 
down, picks up the forks on the left and right, consumes 
spaghetti for a random amount of time, puts down the forks, 
and stands up again. If all D philosophers sit down at once, 
pick up the fork on their left, and then try to pick up the right 
fork, they will deadlock waiting for the philosopher on their 


UnaryPredicate clearPaymentPredicate = 
new UnaryPredicate ( } { 

public boolean execute (Ob ject o) ( 
if (o instanceof Task) { 

Task task = (Task) o; 
if ( (task. get Verb () != null) && 

task, get Verb () .toStringO . equal s{ 
BolSocietyUtils . PAYMENT__VERB) ) { 
return true; 

} 

} 

return false; 

) 

}? 

Figure 3. UnaryPredicate code 


process 

Pi = 
let 

process 
Pred(o) = 

if Task e o. types and 
< verb , PA YMENT„ VERB > 
e o. attributes 
then SKIP 
else pi 
Act(o) = 
j3i\add — ► 

Pi [ . < {Object, String}, 

{< value, PAID >} >-* SKIP 
Pile -► pilo — + 

if e = add then Pred(o) § Act(o) g pi 
else pi 


Figure 4. Example Plugin 


right to put down the forks. To illustrate the model’s use, a 
CSP/Cougaar model of the problem is provided, followed 
by the description how the deadlock occurs. 

Three CSP abstraction processes are used as subroutines 
to add, remove, and listen for objects on the Blackboard. 
The listener removes the object it founds (Figure 5). 

5.1. Forks 

Figure 6 shows that reservation and allocation sub- 
processes are executed repeatedly. The reservation sub- 
process waits for a Request object to be placed on the 
Blackboard, specifying a get of the fork t. The alloca- 


process 

Post{o) = /3 n ladd — /3 n \o - SKIP 


process 

Remove(o) = (3 n \remove — ► 0 n \o —► SKIP 


process 

Listen(o) = p n le — > p n lp -4 
if 

o. types € p. types 
and o. attributes € p. attributes 
then Remove (o) 
else Listen (o) 


Figure 5. Abstraction Processes 


don process posts a Response object to the Blackboard, 
mirroring the parameters of the Request . 


5.2. Philosophers 

All a philosopher does is to repeatedly get the two forks 
and release them in left-to-right order. The philosopher’s 
sitting, standing, and eating states are not relevant for the 
deadlock problem. As shown in Figure 7, there are two sub- 
processes for getting and releasing the forks (% denotes the 
modulus operator). 


53. Deadlock 

A deadlock state of the system is described by provid- 
ing an ordered list of events that prevents any subsequent 
event. First two philosophers and two forks are shown in 
Figure 8 . Only the relevant events are described; add events 
of requests or responses that try to get or to release a fork. 
Each philosopher successfully gets a left fork. The first at- 
tempt to acquire a right fork will cause deadlock. It is im- 
portant to note that releases of forks are not ignored; none 
actually occurs here. To prove that a system does not dead- 
lock is far more difficult. CSP provides rewriting rules and 
equivalence relations to help analyze a model for a specific 
property. 


process 
FORKi = 
let 

process 

Reserve(i) — 

Listen( 

< {Request}, 

{< id,i >, < act , get >} > 

) 

g Post( 

< { Object , iZesponse}, 

{< id, i >, < act, pet >} > 

) 

AZfocafe(i) = 

Z/isten( 

< {ite^uest}, 

{< id,i >,< act, release >} > 

) 

g Post( 

< {Object, Response}, 

{< id,i >,< act, release >} > 

) 

Reserve(i) g Allocate(i) g FORKi 


Figure 6. Forks 


6. Conclusions 

Hoards CSP can be used as a formalism for modeling 
and analyzing distributed multi-agent systems. A basic CSP 
model of a Cougaar system can be generated in parallel with 
the CMDA generated Cougaar code. It provides a model 
for analyzing the interactions of agents, their Plugins, and 
Blackboards. A CSP tool is then used to detect deadlocks 
or to determine other CSP properties. 

While the described approach simplifies some character- 
istics of the Cougaar agents and related components, it is 
a stepping stone towards a more complete analysis. Cur- 
rent research focuses on completing the CMDA develop- 
ment where the major focus is on the formal validation of 
the generated Cougaar code. 
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process 

Pi = 
let 

process 
Get(i,s) = 

Post( 

< { Object, Request }, 

{< id,i>,< act, get >, 

< side,s >} > 

) 

g Listen{ 

< {Response}, 

{< id, i >, < act, get >} > 

) 

Release(i, side) — 

Post( 

< {Object, Request}, 

{< id,i >,< act, release >, 

< side,s >} > 

) 

g Listen ( 

< {Response}, 

{< id,i>,< act, release >} > 

) 

Get (i, left ) g Get ((i + 1 )%N, right) 
g Release(i, left) 
g Release((i + 1)%#, right) g pi 


Figure 7. Dining Philosophers 


failure = 

( add, < {Request}, 

{< id, 1 >, < act, get >, < side, left >} >, 
add , < {Response}, {< id, 1 >, < act, get >} > 
add, < {Request}, 

{< id, 2 >, < act, get >, < side, left >} >, 
add, < {Response}, {< id, 2 >, < act, get >} >, 
add, < {Request}, 

{< id, 2 >, < act, get >, < side, right >} > 

...) 

Figure 8. Deadlock state 
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